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Foreword 



This Technical Specification (TS) has been produced by ETSI Project Telecommunications and Internet Protocol 
Harmonization Over Networks (TIPHON). 

The present document is part 1 of a multi-part deliverable covering implementation, of TIPHON architecture using the 
SIP protocol, as identified below: 

Part 1: "Implementation of TIPHON architecture using SIP"; 

Part 2: "Implementation Profile for SIP" . 
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Scope 



The present document describes how the SIP protocol [9] completed with correlated protocols like SDP [11], 
HTTP [12] can be a candidate for TIPHON release 4 according to guidelines given in TS 101 315 Release 4 (see 
bibhography) and TS 101 315 Release 3 [2]. 

The SIP profile is derived from the examination of the following TIPHON Release 4 documents: 

• the TIPHON baseline architecture described in TS 101 314 [1]; 

• the capabilities service required by TS 101 878 (see bibliography); 

• the Meta-protocol as defined in multi part document TS 101 882-1 [5], TS 101 882-2 [6], TS 101 882-3 (see 
bibliography), TS 101 882-4 (see bibhography) and TS 101 882-5 [7]; 

• the end-to-end Quality of Service defined in TS 102 024-3 [3]; 

• the Security service defined in TS 102 165-1 [4]. 

The mapping of Meta-Protocol to SIP is limited to the following parts, while other parts are not available yet like 
supplementary services: 

• Registration Meta-Protocol [6]; 

• Simple Call Meta-Protocol (TS 101 882-3 - see bibliography); 

• Media Control Meta-Protocol (TS 101 882-4 - see bibliography); 

• the end-to-end Quality of Service defined in TS 102 024-3 [3]; 

• IETF RFC 3261: "SIP: Session Initiation Protocol" [9]; 

• IETF RFC 2327: "SDP: Session Description Protocol" [11]; 

• IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1" [12]; 

• IETF RFC 2617: "HTTP Authentication: Basic and Digest Authentication" (see bibliography); 
Furthermore the following documents have been consulted for information: 

• TS 124 229: "IP Multimedia Call Control Protocol based on SIP and SDP" (see bibhograpy); 

• TS 124 228: "Signalling flows for the IP multimedia call control based on SIP and SDP" [8]. 
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3.1 



Definitions and abbreviations 



Definitions 



For the purposes of the present document, the terms and definitions given in TS 101 314 [1] and TS 101 878 (see 
bibliography) apply. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

B2BUA Back-to-Back User Agent 

BC Bearer Control 

CC Call Control 

COPS Common Open Policy Service 

FG Functional Group 

ICE Inter-Connect Function 

IP Internet Protocol 

MC Media Control 

NFG Network Functional Group 

PCM Pulse Code Modulation 

PDP Policy Decision Point 

PSTN Public Switched Telephone Network 

QoS Quality of Service 

RPC Remote Procedure Call 

SAP Service Access Point 

SC Service Control 

SDP Session Description Protocol 

SpoA Service point of Attachment 

TE Terminal Equipment 

UA User Agent 

UAC User Agent Client 

UAS User Agent Server 

URI Uniform Resource Identifier 



4.1 



SIP environment overview 



Introduction 



The purpose of the present document is not to describe how to implement SIP protocol but how TIPHON protocol can 
be represented in a SIP environment. For example parameter mandatory in SIP but without equivalence in TIPHON 
information elements are not documented. Mandatory behaviours in SIP that do not correspond to any TIPHON 
behaviours are not documented either. 

The aim is to identify gap in TIPHON to SIP direction between both protocols. Informative suggestions to fill those 
gaps could be given in conclusion. 



£75/ 



ETSI TS 101 884-1 V4.1.1 (2003-08) 



4.2 SIP protocol 



SIP is a relatively new technology (1995) developed for remote control, establishment and tear-down of multimedia 
sessions. The origins of SIP are in the academic and IETF community and assumed in its first incarnation a public 
internet although with the interest shown by 3GPP the application to a managed network that uses IP has become 
ascendant. SIP is based upon the communication model of HTTP and therefore is broadly viewed as a request-response 
protocol. In relation to other well known protocols SIP has close cousins in Remote Procedure Call (RPC) and in the 
ITU-T ROSE protocol. 

According to RFC 3261 [9], SIP is an application-layer-control protocol to manage multimedia session. But, "SIP is not 
a vertically integrated communications system", and will need other IETF protocols to build a complete multimedia 
architecture (e.g.: RTP RFC 1889 [15], RTSP RFC 2326 [18], MEGACO RFC 3525 [19], SDP RFC 2327 [11]). 

The choice of the protocol for the session description is opened in SIP and appears in SIP only as a parameter value 
(Content-Type). The media type descriptions that can be included in the body of a SIP message are Internet Media 
Types as in HTPP/1.1. However, in this profile only Session Description Protocol (SDP) defined in RFC 2327 [1 1] has 
been considered. SIP reuses also the authentication mechanism defined in HTTP. 

The SIP technology has been considered through the following standards: 

• "SIP: Session Initiation Protocol" - RFC 3261 [9]. 

• "SDP: Session Description Protocol" - RFC 2327 [11]. 

• "RTP Profile for Audio and Video Conferences with Minimal Control" - RFC 1890 [14]. 

• "Hypertext Transfer Protocol - HTTP/1 . 1 " - RFC 26 1 6 [ 1 2] . 

SIP does not define services. Rather, SIP provides primitives that can be used to implement different services. For 
example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a 
session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same 
primitive is used to deliver a photo of the caller as well as the session description, a "caller ID" service can be easily 
implemented. As this example shows, a single primitive is typically used to provide several different services. 

SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference 
is to be managed. SIP can be used to initiate a session that uses some other conference control protocol. Since SIP 
messages and the sessions they establish can pass through entirely different networks, SIP cannot, and does not, provide 
any kind of network resource reservation capabilities. 

The nature of the services provided make security particularly important. To that end, SIP provides a suite of security 
services, which include denial-of-service prevention, authentication (both user to user and proxy to user), integrity 
protection, and encryption and privacy services. 

SIP works with both IPv4 and IPv6. 

4.2.1 SIP signalling, methods and responses 

4.2.1.1 SIP signalling 

The SIP protocol client/server machine is very simple: Request is sent and the requestor (client) waits for a response. 
The request contains the method and who the method is aimed at, the response contains the status code that informs the 
requestor of how the server has dealt with the request. 

4.2.1 .2 Methods and responses 

There are 6 core methods in SIP and these are the basis of the protocol: 

• INVITE - starts a session (and modifies it if used as a re-invite). 

• ACK - confirms the invite. 

• BYE - terminates a sessions. 
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• CANCEL - cancel an invite. 

• OPTIONS - Querying capability. 

• REGISTER - binds a user's address (SIP name) to a network address (IP address). 



4.2.2 SIP protocol components 



The protocol of SIP is enabled by assigning particular functions to a set of protocol components. A particular SIP 
device will contain 1 or more of these components. 

User Agent Client (UAC). 

User Agent Server (UAS). 

Redirect server. 

Proxy server. 

Registrar. 

The UAC and UAS exist in a normal terminal device and are termed jointly the User Agent. 

The proxy server arises from breaking the assumption that the UACs know the UASs that they want to communicate 
with. In anything but the smallest of networks this assumption is inevitably broken so a network resident proxy to the 
UA exists to facilitate routing. 

• Proxy servers can be configured to perform inter-domain call establishment. 

• The registrar server is a special server that attends to REGISTER methods. In most cases the registrar and 
proxy server will be co-located. 

4.3 SDP 

SDP is a session description protocol in text format language. It is used in SIP to define a simple offer/answer model to 
a describe unicast session. Mapping in the present document has been based on RFC 2327 [11] overloaded with 
RFC 3264 [10]. 

4.4 HTTP/1.1 

Hypertext Transfer protocol provides a scheme description for authentication. 

According to RFC 3261 [9], chapter 22, only the "Digest" authentication mechanism described in RFC 2617 [13] 
overload by RFC 3261 [9] has to be considered. 



5 Implementation of TIPHON functional architecture 

using SIP 

5.1 Introduction 

5.2 SIP functional architecture 

The SIP Architecture has the following functional elements, as defined in [9]. 

User Agent (UA): The user agent is the functional entity that may initiate or respond to a SIP request. 
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In a TIPHON compliant system, the SIP User Agent (UA) shall provide the functionality of the terminal functional 
group. The terminal functional group performs the roles of the terminal registration functional group, originating 
terminal functional group and the terminating terminal functional group. The reference points SI, SCI and Nl are 
regarded as internal to the TE. 

Back-to-Back User Agent (B2BUA): B2BUA is a logical entity that receives a request and processes it as a User 
Agent Server (UAS). In order to determine how a request should be answered, it acts as a User Agent Client (UAC) and 
generates requests. Unlike a proxy server (stateless), it maintains a dialogue state, and must participate in all requests 
sent on the dialogues it has established. TIPHON recommends the use of a B2BUA, as network functional groupings 
involved in providing a service. 

Proxy server: A proxy server acts as both the client and server: It receives a request from an entity, and initiates a 
request on behalf of the requesting entity, hence acting as a server for the requesting entity. A proxy server can be 
stateless (forgets about the state of a particular session) or statefull (keeps track of the state of the session it is involved 
in). 

Redirect server: A redirect server receives requests from an entity, and returns the contact address of the destination to 
the resquesting entity. 

Registrar: The registrar processes registration requests; as a minimum this involves updating the users contact list and 
responding to the originator of the request. Typically a registrar is co-located with either the proxy or the redirect server, 
and may be adapted to perform location-based services. 

SIP gateway: A SIP gateway acts as an interworking medium between the PSTN and a SIP network. It provides an 
interworking between SIP and PSTN call control protocols, such as ISUP, as well as interworking between the TDM 
and IP media flows. A SIP gateway can be decomposed into a gateway controller (taking cate of the call control 
protocol conversion) and a media gateway (taking cate of the TDM to IP media conversion). 

Figure 1 shows how the SIP functional elements map onto the functional layers in the IP Telephony Application plane. 

Figure 1 : Void 

The UA maps to Service, Service Control (SC), Call Control (CC), and Bearer Control (BC) layers. 

The statefull and stateless proxy maps to the TIPHON service control, call control and bearer layers. 

The SIP gateway covers all TIPHON layers. 

The redirect server works at TIPHON service control and call control layers. 

The registrar works at TIPHON Service and Service Control layer. 

Figure 2 shows the SIP entities and how they map to the functional layers and the Functional Groups (FG) defined in 
TS 101 314 [1]. 
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NOTE 1 : All entities in an IP network "normally" use the DNS service. In the context of the present document only 

relations to the DNS with ENUM extensions are shown. 
NOTE 2: The gateway shown is a decomposed gateway (combination of a gateway controller and a media 

gateway). 

Figure 2: SIP Architecture mapped to the TIPIHON Functional layers and functional groups 

The SIP proxy, SIP gateway and the SIP Registrar shall provide the functionality required in the Network Functional 
Group (NFG). Reference point S2, S3 and Ag^ are between the Network Functional Group and other IP Network 
services e.g. DNS. The Network Functional Group may play the roles of an originating Network Functional Group, an 
intermediate Network Functional Group or a terminating Network Functional Group. 

NOTE: The Network Functional Group may include Media Control Functional Entities, e.g. for giving 

announcements, mixing media streams etc. This is, however, out of scope of the present document. 

The present document describes the mapping of functional architecture TS 101 314 [1], as well as the context, 
behaviour and procedures TS 101 882-1 [5] that the SIP and SDP protocols must adhere to, to be TIPHON compliant. 
In TIPHON Release 4, SIP is mapped to reference points Rl, R2, CI, C2, where Rl and R2 refer to the registration 
reference points, whereas CI and C2 refer to call & bearer control reference points. The R and C reference points will 
be dealt with separately in the present document, because of the different nature of services they provide. 



Registration service 



6.1 



Introduction 



According to the meta-protocol defined in TS 101 882-2 [6] and functional the description defined in TS 101 315 [2], 
the purpose of the TIPHON registration service includes the authentication and authorization of a subscriber 
(user/registrant) to access a service. 

The basic registration mechanism can be described as follows: 

1) User registration: The user registers for the service and shows entitlement for the service used. 

2) Service preparation: The registrar selects a service node at which the user shall use the service and informs the 
service node that the user is entitled to use the service. 

3) Service attachment: The user (terminal) attaches to the service node and the service can be delivered. 
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Two registration scenarios shall be supported: 

• the "User at home" scenario; 

• the "Roaming user" scenario. 

Registration in SIP is part of a location service. With the REGISTER message a UA informs location server how it 
could be contacted. This functionality is a bit far from Registration service as defined in TIPHON. However, the 
REGISTER message contains a Proxy-Authorization header field that allows an authentication and authorization 
mechanism. This mechanism can be explicitly requested by the Service point of Attachment with a Proxy- Authenticate 
header in a 407 (Proxy Authentication Required) Response. This field will be set by the UA and analysed by the Proxy 
SpoA. RFEl and RFE2 have to be the same SIP entity. 

Consequently, there is not always a one to one mapping between TIPHON registration information flow sequence and 
SIP registration signalling. For example the UA sends one or two REGISTER messages depending if the UA is waiting 
for 401, 407 responses before setting Proxy- Authorization header. The REGISTER message will cover both 
information flows Registration_req and Authorize_r. In case of "User at home" RFE2 and RFE3 can be considered as a 
SIP outbound proxy and the REGISTER message is mapped with Registration_req and Authorize_req. In case of 
"Roaming user" the REGISTER message will be forwarded by proxies that behave as Originating NFG and 
intermediate FG to RFE2/RFE3. The initial REGISTER message shall contain information useful in both 
Registration_req and Authorize_req and will be set by the UA. 

Additionally, in case of "Roaming user", an intermediate proxy between RFEl and RFE2 may require a SIP registration 
from RFEl before any TIPHON registration. This is implementation dependant. In pure IP environment RFEl can 
address directly its registration to RFE2 or has to go through an intermediate proxy. In both case it will have to know 
the IP address, port and transport protocol of its home network. This can be done statically. The UA will have to know 
also its current domain name address to set at its contact address. 

De-Registration and Registration in SIP are covered by the same protocol message REGISTER. 

According to RFC 3261 [9], chapter 22 "Basic" authentication is not allowed in SIP, only "Digest" authentication 
mechanism described in RFC 2617 [13] overload by RFC 3261 [9] can be used. Authentication parameters value is 
given in the following table for a "Digest" mode. Authentication parameters are given in unsuccessful message in SIP 
while they are expected in successful message in TIPHON. This makes some distortion in the mapping. 

Deregistration in SIP uses the same REGISTER message with the expire parameter set to zero on the contact to remove 
or a contact list set to * (meaning all contact) and an Expires header field set to 0. The registrar cannot ask to the user 
for deregistration. 
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A SIP registration signalling flow could be: 



UA Regstrant 


Originating Network 


Intermediate Network 


Terminating Network 


Registrar/SpoA 



SIP Terminal SIP outbound proxy 



REGISTER 



407 Proxy Authentica tion required 



REGISTER with 
Proxy-Authorization; Valhe 1 



200 OK 



REGISTER 



407 



REGISTER with 
Proxy-Authorization : 
Proxy-Authorization : 



200 OK * 



SIP proxy 



REGISTER forwarded 



Value 



407 



V^lue 1 
2 
REGISTER forwarded 



200 OK 



SIP proxy 



SIP Proxy 



REGISTER forwarded 

► 



407 



REGISTER forwarded 



200 OK 



REGISTER forwarde(P 

► 



407 



REGISTER forwardec 



200 OK 



Figure 3: The SIP registration example 



6.2 Registration functional entities mapping 

Table 1 : Mapping of SIP entities to TIPHON Registration Functional entities 



TIPHON functional element 


SIP entities | 


Identity 


TIPHON Description 


User at Home 


Roaming User 


RFE1 


Registrant, the logical entity being registered 


UA 


UA 


RFE2 


Registrar, holder of user profile of the 
registrant 


Registrar 


Registrar 


RFE3 


Serving Service Provider point of Attachment 
(SpoA) 


Outbound Proxy 


Home Proxy 


RFE4 


Previous SpoA 


Proxy 


Proxy 



6.3 Registration IVIessages IVIapping 

Table 2 shows the mapping of TIPHON Registration meta-protocol information flows to SIP messages. 

Responses to these requests, when a SIP message corresponds, are done with SIP responses described in RFC 3261 [9], 
chapters 7.2 and 20. A 2XX answer corresponds to a positive answer while a 4XX-6XX answers to a reject. 



£75/ 



15 



ETSI TS 101 884-1 V4.1.1 (2003-08) 



Table 2: Mapping of SIP messages to TIPHON Registration lUIPMUs 



TIPHON message 


Relationship ID 


SIP messages 


Register 


RFE1<->RFE2 


REGISTER/SIP Response 


DeRegister 


RFE1<->RFE2 


REGISTER with contact header field set to * and Expires 
header field set to 0/SIP Response 


Authorize 


RFE2<->RFE3 


None 


Detach 


RFE2<->RFE3 


None 


Attach 


RFE3<->RFE1 


Proxy-Authorization header field in SIP message concerned 
by the service invocated 


Detach 


RFE2<->RFE4 


None 



6.4 Registration information flow IVIapping 
6.4.1 Relationship ra (RFE1/RFE2) 

Table 3: IVIapping of SIP to Register request from RFE1 to RFE2 



Register request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


TIPHON-reg-id 


M 


Any 


URI in the TO header 
(address-of-record) 
and username 
parameter in Proxy- 
Authorization header 


TO and FROM SIP header 
can differ while for roaming 
user scenario a third party 
Registration is needed 


Registration IVIode 


M 


Initial registration 
Location update 


None 


There is no distinction 
between Initial registration 
and updating Contact in SIP 
from data point of view. 
Only behaviour requesting 
the authorization (401,407 
Responses) can reflect a 
first registration. 


Location (of Registrant) 


M 




Contact header set to 
the current location of 
the registrant 






protocol! D 






Fixed value 'sip' used 
in addr-spec 




nameorAddress 






Name-addr or addr- 
spec of Contact 




port 






Port of hostport of 
addr-spec used in 
Contact 




ServlceName 


M 


TIPHON Simple 
Gall... 


Could be set as part 
of realm value in 
Proxy-Authorization 
header 
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Table 4: Mapping of SIP to Register response from RFE2 to RFE1 



Register response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


TIPHON-reg-id 


M 


Any 


URI in the TO header 
(address-of-record) 




ServiceName 



(see note 2) 




None 




Result 


M 


Registration 
successful. 
Registration- 
Id invalid. 
Service 
unavailable 


Status-Code 


200 OK/407 Proxy 
Authentication require?, 
406 Not Acceptable, 503 
Service Unavailable 


ServiceProviderName 




(see note 1 ) 


Any 


None 




ClientAuhorizationToken 



(see note 1 ) 


Any 


Opaque parameter of 

Proxy-Authenticate 

header 


(see note 1) 

According to this note and 
note 3, there is no 
mapping in flow sequence 


NOTE 1 : Provided if Result='Registration successful'. 

NOTE 2: Provided if Result='Service unavailable'. 

NOTE 3: This value will be present only 407 reject response. 



Table 5: lUlapping of SIP to DeRegister request from RFE1 to RFE2 



DeRegister request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


TIPHON-reg-id 


M 


Any 


URI in the TO header 
(address-of-record) and 
username parameter in 
Proxy-Authorization header 




ServiceName 


M 


TIPHON Simple 
Call... 


Could be set as part of realm 
value in Proxy-Authorization 
header 





Table 6: Mapping of SIP to DeRegister response from RFE2 to RFE1 



DeRegistration response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


TIPHON-reg-id 


M 


Any 


URI in the TO header 
(address-of-record) 




Result 


M 


Deregistration 
successful, 
Registration-Id 
invalid 


Status-Code 


200 OK, 406 Not 
Acceptable/407 Proxy 
Authentication require? 
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6.4.2 Relationship rb (RFE2/RFE3) 

Even if no SIP signalling flow is defined between RFE2 and RFE3 a pseudo mapping has been tried with the data 
contains in the REGISTER message received by RFE2. 

Table 7: Mapping of SIP to Authorize request from RFE2 to RFE3 



Authorize request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Registrar-id 


M 


Any 


Domain set in uri parameter 
of Proxy-Authorization 
header 




TIPHON-reg-id 


M 


Any 


URI in the TO header 
(address-of-record) and 
username parameter in 
Proxy-Authorization header 




ServiceName 


M 


TIPHON Simple 
Call... 


Could be set as part of 
realm value in Proxy- 
Authorization header 





Table 8: Mapping of SIP to Authorize response from RFE3 to RFE2 



Authorize response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Registrar-id 


M 


Any 


Domain set in domain 
parameter of Proxy- 
Authenticate header 


note 1 


TIPHON-reg-id 


M 


Any 


URI in the TO header 
(address-of-record) 




ClientAuthorizationToken 




(note 2) 


Any 


Opaque parameter of 

Proxy-Authenticate 

header 


notes 1 and 2 create a 
mismatch in the flow 


Result 


M 


ServiceAuthorized to 
Client, ResourceNot 
available 


Status-Code 


200 OK, 503 Service 
Unavailable 


NOTE 1 : This value will be present only 407 reject response and will have to be picked up before a successful 

answer. 
NOTE 2: This information element shall be provided if the value of Result is 'OK'. 



Table 9: Mapping of SIP to Detach request from RFE2 to RFE3 



Detach request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Registrar-id 


M 


Any 


Domain set in uri parameter 
of Proxy-Authorization header 




TIPHON-reg-id 


M 


Any 


URI in the TO header 
(address-of-record) and 
username parameter in 
Proxy-Authorization header 




ServiceName 


M 


TIPHON Simple Call... 


Could be set as part of realm 
value in Proxy-Authorization 
header 
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Table 10: Mapping of SIP to Detach response from RFE3 to RFE2 



Detach response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Registrar-id 


M 


Any 


Domain set in domain 
parameter of Proxy- 
Authenticate header 


(see note 1 ) 


TIPHON-reg-id 


M 


Any 


URI in the TO header 
(address-of-record) 




Result 


M 


Service detachment 

successful 

Identity not recognized 


Status-Code 


200 OK, 404 Not 
Found/407 Proxy 
Authentication require? 


NOTE 1 : This value will be present only 407 reject response. 

NOTE 2: This information element shall be provided if the value of Result is 'OK'. 



6.4.3 Relationship re (RFE1 /RFE3) 

The data are mapping only with the header field SIP Proxy- Authorization included in the SIP message correlated to the 
service invocated. 

Table 11 : Mapping of SIP to Attach request from RFE2 to RFE3 



Attach request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Registrar-id 


M 


Any 


Domain set in uri 
parameter of Proxy- 
Authorization header 




TIPHON-reg-id 


M 


Any 


username parameter 
in Proxy-Authorization 
header 




ServiceName 


M 


TIPHON Simple 
Call... 


Could be set as part of 
realm value in Proxy- 
Authorization header 




AuthorizationToken 


M 


Any 


Opaque parameter of 
Proxy- Authorization 
header 





Table 12: Mapping of SIP to Attach response from RFE3 to RFE2 



Attach response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Registrar-id 


M 


Any 


None 




TIPHON-reg-id 


M 


Any 


None 


Proxy-Authenticate header is 
not sent in response when a 
valid Proxy-Authorization has 
been sent in the request 


Result 


M 


Service attachment 

successful 

Identity, not recognized. 

Authorization expired 


Status-Code 


200 OK, 407 Proxy 
Authentication require, None 



6.4.4 Relationship rd (RFE2/RFE4) 



No mapping can be done. 
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6.5 Registration action IVIapping 



Table 13: Mapping of SIP to Registration action at RFE1 



Actions at RFE1 


TIPHON Action 
number 


SIP behaviour 


101 


Preparation and Sending of first REGISTER message without Proxy-Authorization. 


102 for initial 
Registration 


Pick up Proxy-Authenticate header in the 407 answer. 


102 for location 
update 


Wait for 200 OK response containing the new contact list. 


103 


Sending of an additional REGISTER message with a valid Proxy-Authorization header. 


104 


Wait for 200 OK response, save this Proxy-Authorization header for future use in request. 


105 


Preparation and Sending of a REGISTER message with Proxy-Authorization header and new 
contact header to update the location 


106 


None 


107 


Preparation and Sending of a REGISTER message with Proxy-Authorization header, contact 
header field set to * and Expires header field set to 


108 


Wait for 200 OK response 



Table 14: Mapping of SIP to Registration action at RFE2/RFE3 



Actions at RFE2/RFE3 


TIPHON Action 
number 


SIP behaviour 


201/202/203/204 

301/302/303/304 

for initial Registration 


Preparation and Sending of a 407 Answer with a Proxy-Authenticate header. 


201/202/203/204 
for location update 


Preparation and Sending of a 200 OK answer with updated contact list. 


205/305/306 


Answering with a 4xx-6xx response 


206 


None 


207 


Updating of the contact list 


208/209/307 


Updating of the contact list 


210/308 


Answering with a 200 OK response without any contact 


211 


Answering with a 4xx-6xx response 



Table 15: Mapping of SIP to Registration action at RFE4 



Actions at RFE4 


TIPHON Action number 


SIP behaviour 


401 


None 


402 


None 



6.6 



Conclusion 



The SIP registration service does not cover completely the TIPHON meta-protocol intention. Additional IETF extension 
to the protocol should be considered. 

Concerning DeRegistration initiated by RFE2, RFC 3265 [20] has been already studied. RFC 3265 [20] allows to 
manage events for registrations in SIP. RFC 3265 [20] will allow exchange (NOTIFY) between Registrar RFE2 and 
Service providers RFE3 and RFE4. But this implies that first RFE3 and RFE4 subscribe to RFE2, which is not 
described in the meta-protocol and additionally RFE3 and RFE4 will receive yet only information on the registration 
state for a particular address-of-record ("init", "active", "terminated"). The Authorization mechanism with the registrant 
still has to be managed in the registrar. This mechanism is used in 3GPP to ask with a NOTIFY sent to the registrant a 
deregistration (RFEl is the subscriber). 
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Simple call application 



7.1 Introduction 

The intentions with this clause is to describe the simple call application defined in the Meta-protocol in 

TS 101 882-3 (see bibliography) using procedures defined in SIP (RFC 3261 [9]) and map those procedures to the 

architecture of TS 101 314 [1]. RFC 3264 [10] has been considered in this process concerning SDP (RFC 2327 [11]). 

Two scenarios shall be supported: 

• the "user at home" scenario; and 

• the "roaming user" scenario. 

NOTE: For details about the two scenarios (including some examples) see the TS 101 315 (see bibliography). 
The simple call application includes following services: 

1) A calling User establishes a call via its home network with a called User. 

2) An authorization mechanism based on the result of the registration is proceeded. 

3) This call can be released either by the calling User, the called User or the network. 

4) The media path is reserved and connected while the call is establishing. 

The ringing tone is local in TIPHON and not a bearer on a media channel. 

It is implicit in TIPHON that the release message will go through the same node as the call Setup where resources have 
been reserved. To guarantee this, record-route and route procedures in SIP will have to be used while the call is 
established by the proxy in charge of the media. 

In case of roaming scenario, several proxies can act between the Calling User and its Home proxy (covered by CFEl, 
CFE2, CFE3, CFE4, CFE5) but have no correspondence in simple call functional entities. 

The UA will have to include in its INVITE a proxy-authorization header field set to the parameter value received during 
the registration. 

The SIP simple call signalling flows could be as in following figures. 



£75/ 



21 



ETSI TS 101 884-1 V4.1.1 (2003-08) 



Calling 
UA 


Originating 
Network 


Home 
Network 


Intermediate 
Network 


Terminating 
Network 


Called 

UA 



SIP Terminal SIP outbound proxy Home proxy SIP proxy SIP proxy SIP 

(SpoA) Terrplnal 



INVITE with 



Proxy-Authorization : 



Vaiue 1 
Proxy-Authorization : 
Value 2 

100 Trying 



180 Ringing 



200 OK 



ACK 



INVITE 



1 00 Trying 



180 Ringing 



^ 180 Ringing 



200 OK 



ACK 



INVITE 



^ 180 Ringing 



200 OK 



ACK 



Media Path 



INVITE 



200 OK 



ACK 



INVITE 



1 00 Trying 



180 Ringing 



200 OK 



ACK 



Figure 4: SIP successful simple call 
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Calling 
UA 


Originating 
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Home 
Network 


Intermediate 
Network 


Terminating 
Network 


Called 

UA 



SIP Terminal SIP outbound proxy Home proxy SIP proxy SIP proxy SIP 
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BYE 



200 OK 



BYE 



1 00 Trying 



200 OK 



BYE 



200 OK 



BYE 
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BYE 
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Figure 5: SIP call release while a call has been established 
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Calling 
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Called 
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Figure 6: SIP call release while a call is still not established 
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7.2 



Simple call functional entities mapping 

Table 16: Mapping of SIP entities to TIPHON simple call functional entities 



TIPHON functional element 


SIP entities | 


Identity 


TIPHON Description 


User at Home 


Roaming User 


Calling User 


The application at the calling user"s terminal 
which instigates the service request 


UA Client 


UA Client 


CFEI0UA 


The originating user service agent in the 
calling user"s terminal that instigates the 
service request 


Home stateful Proxy 
in the same current 
domain of the UA 
(Server Part) 


Home stateful Proxy 
(Server Part) 


CFE2pE 


The serving network policy control function 
associated with the calling user"s service 
provider 


Home stateful Proxy 
in the same current 
domain of the UA 
(Registrar part) 


Home stateful Proxy 
(Registrar part) 


CFESqcc 


The originating call coordination function that 
is responsible for establishing the call on 
behalf of the calling user 


Home stateful Proxy 
in the same current 
domain of the UA 
(Client Part) 


Home stateful Proxy 
(Client Part) 


CFE4oR 


The originating call routing function, providing 
routing information and number/address 
translations 


DNS 

server/Location 

Server 


SIP routing rules, 
DNS server. 
Location Server 


CFESoT 


The originating transport coordination function 
serving the calling user 


RSVP 


RSVP 


CFE6,cc 


An intervening call control coordination 
function. This CFE is responsible for 
establishing the call via the intervening 
domain 


Intermediate stateful 
Proxy 


Intermediate stateful 
Proxy 


CFE7,R 


An intervening routing function 


DNS 

server/Location 

Server? 


SIP routing rules, 
DNS server. 
Location Server 


CFE8|T 


An intervening transport coordination function 


RSVP 


RSVP 


CFEQjQQ 


The destination call coordination function that 
is responsible for establishing the requested 
call on behalf of the called user 


stateful Proxy of 
called Domain 


stateful Proxy of 
called Domain 


CFE10-n- 


The destination transport coordination 
function serving the called user 


stateful Proxy of 
called Domain 


stateful Proxy of 
called Domain 


CFEHtua 


The service agent that processes an 
incoming call to the called user 


stateful Proxy of 
called Domain 


stateful Proxy of 
called Domain 


Called User 


The application in the called user"s terminal 
at which the service request is terminated 


UA Server 


UA Server 


NOTE: The mapping of SIP protocol entities to TIPHON functional entities shown in this table may not 
be the only mapping possible and it is recognized that alternative mappings may exist. The 
remainder of the present document assumes only the existence of the mapping shown in 
table 16. 



7.3 Simple call messages mapping 

Table 17 shows the mapping of TIPHON simple call meta-protocol information flows to the SIP messages. 

Responses to these requests, when a SIP message corresponds, are done with SIP responses described in RFC 3261 [9], 
chapters 7.2 and 20. A 2XX answer corresponds to a positive answer while a 4XX-6XX answers to a reject and IXX to 
a provisional. To get an alerting at Calling user side, called user will have to send a provisional response IXX that will 
be forwarded even if Alerting flow does not exist on called user side. 
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Table 17: Mapping of SIP messages to TIPHON simple call MPMUs 



TIPHON message 


Relationship ID 


SIP messages 


TCC OrigCallSetup 


Calling User-<>CFE1 


INVITE/SIP Response 


TCC CallRelease 


Calling User<->CFE1 


BYE/CANCEL/SIP Response 


TCC_CallAlerting 


Calling User<->CFE1 


Provisional response like 183 Session Progress or 180 
Ringing 


ServingNwPolicy 


CFE1<->CFE2 


None internal 


CallSetup 


CFE1<->CFE3 


None 


CallRelease 


CFE1->CFE3 


None 


CallAlerting 


CFE1->CFE3 


None 


CallRoute 


CFE3<->CFE4 
CFE6<->CFE7 


None internal or concern other protocol like DNS 


TRMReserve 


CFE3<->CFE5 
CFE6<->CFE8 
CFE9<->CFE10 


Concern other protocol like RSVP 


TRMConnect 


CFE3<->CFE5 
CFE6<->CFE8 
CFE9<->CFE10 


Concern other protocol like RSVP 


TRMRelease 


CFE3<->CFE5 
CFE6<->CFE8 
CFE9<->CFE10 


Concern other protocol like RSVP 


NWCallSetup 


CFE3<->CFE6 
CFE6<->CFE9 


INVITE/SIP Response forwarded 


NWCallRelease 


CFE3<->CFE6 
CFE6<->CFE9 


BYE/CANCEL forwarded 


NWCallAlerting 


CFE3<->CFE6 
CFE6<->CFE9 


Provisional response like 183 Session Progress or 180 
Ringing (except 100 that is local) forwarded 


DestCallSetup 


CFE9<->CFE11 


None 


CallRelease 


CFE9<->CFE11 


None 


TCC DestCallSetup 


CFE11<->CalledUser 


INVITE/SIP Response 


TCC CallRelease 


CFE11<->CalledUser 


BYE/CANCEL/SIP Response 



7.4 Simple call information flow mapping 

Only Call information flows that have an equivalence in SIP have been mapped. 
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7.4.1 Relationship ra (CallingUser/CFE1 ) 

Table 18: Mapping of SIP to TCC_OrigCallSetup request from CallingUser to CFE1 



TCC_OrigCallSetup request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Call Identifier 


M(notel) 


Alphanumeric handle 


Call-ID header 


Complete call leg 
(Call-ID, To, From) 
should better 
identified the call 


Called user ID 


M 


TIPHON user name 


SIP-URI contained in To header 




Calling user ID restriction 


M 


Available/unavailable 


None 


Always set to 
available in SIP 


Calling user ID 




(note 2) 


TIPHON user name 


SIP-URI contained in From 
header 


Always present 


Operator selection 





OperatorSelection 


None 




Service Offer Ticket 


M 


TicketType 


Proxy-Authorization header 






registrantid 


M 


Visiblestring 


username parameter in Proxy- 
Authorization header 




Registrarld 


M 


Visiblestring 


Domain set in uri parameter of 
Proxy-Authorization header 




serviceCredential 


M 


ServiceCredentialType 








serviceAppId 


M 


Visiblestring 


Could be set as part of realm 
value in Proxy-Authorization 
header 




spoA 


M 


Visiblestring 


Domain set in uri parameter of 
Proxy-Authorization header 


In SIP SpoA is 
equivalent to the 
Registrar so its 
domain name can 
be reused 


startTime 


M 


GeneralizedTime 


None 




stopTime 


M 


GeneralizedTime 


None 




cryptoDigest 





Visiblestring 


Opaque parameter of Proxy- 
Authorization header 


note 3 


cryptoDigest 





Visiblestring 


Opaque parameter of Proxy- 
Authorization header 


note 3 


OoSServiceClass 


M 


enumerated Value 


SDP parameters 


a=quality:<quality> 
SDP line could be 
used 


TrafficDescriptor 


M 


TrafficDesc 


SDP parameters 


Derived to 
a=ptime: 




peakFrameRate 


M 


Integer 


None 




maxFrameLength 


M 


Integer 


None 




Codec 


M 


List of possible codecs 


SDP parameter encoding name 
in a=rtpmap: lines 


note 4 


Transcode count 


M 


Number of codec 
transcoding 


Number of SDP lines starting with 
a=rtpmap: and with different 
encoding name set 


note 4 


Previous Domain Egress 
point 


M 


Network specific 
address 


SDP parameter c= and port set in 
SDP parameter m=audio 


A SDP parameter 
a= has to be set to 
sendrcv value. 
Because only one 
port can be set, 
one m=audio line 
shall be contained 
in the SDP offer. 


NOTE 1 : A temporary Call Identifier value may be used in the call setup request. 

NOTE 2: Shall be present if 'Calling User ID restriction' information element is set to value 'available'. 

NOTE 3: One at least has to be set. 

NOTE 4: For a RTP/AVP transport (parameter SDP m=audio) according to RFC 1890 [14] and RFC 2327 [11]. 
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Table 19: Mapping of SIP to TCC_OrigCallSetup response from CFE1 to CallingUser 



TCC OrigCallSetup response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


■mapping 


Notes 


Call Identifier 


M 


Alphanumeric handle 


Call-ID header 


Complete call leg 
(Call-ID, To, From) 
should better 
identified the call 


Codec 




(notes 1 and 2) 


List of possible codecs 


SDP parameter encoding 
name in a=rtpmap: lines 


only one a=rtmap 
SDP line shall be 
present with a port 
set to a non null 
value in the 
m = SDP line. 


Transcode count 




(note 3) 


Number of codec 
transcoding 


Number of SDP lines 
starting with a=rtpmap: and 
with different encoding 
name set 


The port shall be 
set to zero in the 
m = SDP line. 


Next Domain Egress 
point 





Network specific address 


SDP parameter c= and port 
set in SDP parameter 
m=audio 


A SDP parameter 
a = has to be set to 
sendrcv value. 


Result 


M 


- Call established 

Rejection cause 
Transport not 
available 
Called user busy 
Requested QoS 
not available 
Called user 
unknown 
No compatible 
codec available 
Invalid ticket 


-200 OK 

-603 Decline 

-486 Busy here 

-488 Not acceptable Here 

-404 Not found 

-415 Unsupported Media 

Type 

-401 Unauthorized 




NOTE 1 : The list of codecs shall be limited to a single entry in the response. 

NOTE 2: This element shall be included if the result of the request is 'Call established'. 

NOTE 3: This element shall be included if the result of the request is 'No compatible codec available'. 



Table 20: Mapping of SIP to TCC_Cal I Release request from CallingUser to CFE1 



TCC CallRelease request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Call Identifier 


M 


Alphanumeric handle 


Call-ID header 


Complete call leg (Call-ID, To, From) 
should better identified the call 


CauseCode 


M 


- Userlnitiated 

- network Initiated 


None 


In BYE request always set to 

Userlnitiated 

In CANCEL request it depends of the 

context 



Table 21 : Mapping of SIP to TCC_CallRelease response from CFE1 to CallingUser 



TCC CallRelease response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Call Identifier 


M 


Alphanumeric handle 


Call-ID header 


Complete call leg (Call-ID, To, 
From) should better identified 
the call 


Result 


M 


- Successful 

- Failed 


-200 OK 
-4XX to 6XX 
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Table 22: Mapping of SIP to TCC_CallAlerting request from CallingUser to CFE1 



TCC CallAlerting request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


lUlapping 


Notes 


Call Identifier 


M 


Alphanumeric handle 


Call-ID header 


Complete call leg (Call-ID, To, From) 
should better identified the call 



7.4.2 Relationship rf, ri (CFE3/CFE6/CFE9) 

Table 23: Mapping of SIP to NwCallSetup request exchanged between CFE3/CFE6/CFE9 



NwCallSetup request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Call Identifier 


M 


Alphanumeric handle 


Call-ID header 


Complete call leg 
(Call-ID, To, From) 
should better 
identified the call 


Calling user ID restriction 


M 


Available/unavailable 


None 


Always set to 
available in SIP 


Calling user ID 




(note 1) 


TIPHON user name 


SIP-URI contains in From 
header 


Always present 


Called user ID 


M 


TIPHON user name 


SIP-URI contains in To 
header 




PreviousDomainEgresspoint 


M 


Network specific address 


SDP parameter c= and port 
set in SDP parameter 
m=audio 




Bearerldentifier 


M 


Alphanumeric 'handle' 


SDP session id set in o= 


S=<session name> 
SDP parameter is 
not used in SIP 


Transport QoSparameter 


M 


TransportParams 


SDP parameters 


a=quality:<quality> 
SDP line could be 
used 




maximumDelay 


M 


Microseconds 


None 




maxDelayVariation 


M 


IVIicroSeconds 


None 




maxlVlean PacketLoss 


M 


PercentXIOOO 


None 




Transportparametersqualifier 


M 


Enumerated: 

totalRemainingBudget, 

budgetAvailableForDomain 


None 




TrafficDescriptor 


M 


TrafficDesc 


SDP parameters 


Derived to 
a=ptime: 




peakFrameRate 


M 


Integer 


None 




maxFrameLength 


M 


Integer 


None 




Codec 


M 


List of possible codecs 


SDP parameter encoding 
name in a=rtpmap: lines 


note 4 


Transcode count 


M 


Number of codec 
transcoding 


Number of SDP lines starting 
with a=rtpmap: and with 
different encoding name set 


note 4 


Destination Service domain 




(note 2) 


Domain address 


It can be a Route header field 
or domain set in TO header 
field 


It is not necessary 
an IP address 


Calling User Access Point 




(note 3) 


Network specific address 


In Via header field 


Always present in 
SIP 


Routing number 




(note 2) 


Domain address 


Domain set in Request-URI 


It is not necessary 
an IP address 


NOTE 1 : Shall be present if 'Calling User ID restriction' information element is set to value 'available'. 

NOTE 2: This element is available only if by some means routing information or destination network domain can be 

determined. If so, this information may simplify route calculations in other functional groups. 
NOTE 3: The 'Calling User Access Point' may be provided to support the routing decision. 
NOTE 4: For a RTP/AVP transport (parameter SDR m=) according to RFC 1 890 [1 4] and RFC 2327 [11]. 
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Table 24: Mapping of SIP to NwCallSetup response exchanged between CFE3/CFE6/CFE9 



NwCallSetup response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Call Identifier 


M 


Alphanumeric handle 


Call-ID header 


Complete call leg 
(Call-ID, To, From) 
should better 
identified the call 


Next Domain Egress 
point 


M 


Network specific address 


SDP parameter c= and port set in 
SDP parameter m=audio 


A SDP parameter 
a= has to be set to 
sendrcv value. 


Codec 




(notes 1 
and 2) 


List of possible codecs 


SDP parameter encoding name 
in a=rtpmap: lines 


only one a=rtmap 
SDP line shall be 
present with a port 
set to a non null 
value in the 
m= SDP line. 


Transcode count 




(note 3) 


Number of codec transcoding 


Number of SDP lines starting with 
a=rtpmap: and with different 
encoding name set 


The port shall be 
set to zero in the 
m= SDP line. 


Result 


M 


- Call established 

- Rejection cause 

- Insufficient resources 

- Called user busy 

- Transport not 
available 

- Requested QoS not 
available 

- Called user unknown 

- No compatible codec 
available 


-200 OK 

-603 Decline 

-486 Busy here 

-488 Not acceptable Here 

-404 Not found 

-415 Unsupported Media Type 




NOTE 1 : The list of codecs shall be limited to a single entry in the response. 

NOTE 2: This element shall be included if the result of the request is 'Call established'. 

NOTE 3: This element shall be included if the result of the request is 'No compatible codec available'. 

NOTE 4: For a RTP/AVP transport (parameter SDP m=) according to RFC 1 890 [1 4] and RFC 2327 [11]. 



Table 25: Mapping of SIP to NwCallRelease request exchanged between CFE3/CFE6/CFE9 



NwCallRelease request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Call Identifier 


M 


Alphanumeric handle 


Call-ID header 


Complete call leg (Call-ID, To, From) 
should better identified the call 


CauseCode 


M 


- Userlnitiated 

- network Initiated 


None 


In BYE request always set to 

Userlnitiated 

In CANCEL request it depends of the 

context 



Table 26: Mapping of SIP to NwCallRelease response exchanged between CFE3/CFE6/CFE9 



NwCallRelease response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Call Identifier 


M 


Alphanumeric handle 


Call-ID header 


Complete call leg (Call-ID, To, 
From) should better identified the 
call 


Result 


M 


- Successful 

- Failed 


-200 OK 
-4XX to 6XX 
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Table 27: Mapping of SIP to NwCallAlerting request exchanged between CFE3/CFE6/CFE9 



NwCallAlerting request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Call Identifier 


M 


Alphanumeric handle 


Call-ID header 


Complete call leg (Call-ID, To, 
From) should better identified the 
call 



7.4.3 Relationship rl (CFE11 /CalledUser) 

Table 28: Mapping of SIP to TCC_DestCallSetup request exchanged from CFE11 to CalledUser 



TCC DestCallSetup request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Call Identifier 


M 


Alphanumeric handle 


Call-ID header 


Complete call leg 
(Call-ID, To, From) 
should better identified 
the call 


Called user ID 


M 


TIPHON user name 


SIP-URI contains in To 
header 




Calling user ID 




(note 1) 


TIPHON user name 


SIP-URI contains in From 
header 


Always present 


Transport QoSparameter 


M 


TransportParams 


SDP parameters 


a=quality:<quality> 
SDP line could be 
used 




maximumDelay 


M 


Microseconds 


None 




maxDelayVariation 


M 


Microseconds 


None 




maxlVlean PacketLoss 


M 


PercentXIOOO 


None 




Codec 


M 


List of possible codecs 


SDP parameter encoding 
name in a=rtpmap: lines 


note 2 


Transcode count 


M 


Number of codec 
transcoding 


Number of SDP lines 
starting with a=rtpmap: 
and with different 
encoding name set 


note 2 


Previous Domain Egress 
point 


M 


Network specific 
address 


SDP parameter c= and 
port set in SDP parameter 
m=audio 


A SDP parameter 
a= has to be set to 
sendrcv value. 
Because only one port 
can be set, one 
m=audio line shall be 
contained in the SDP 
offer. 


NOTE 1 : Shall be present if 'Calling User ID restriction' information element is set to value 'available'. 
NOTE 2: For a RTP/AVP transport (parameter SDP m=) according to RFC 1890 [14] and RFC 2327 [11]. 
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Table 29: Mapping of SIP to TCC_DestCallSetup response exchanged from CalledUser to CFE1 1 



TCC DestCallSetup response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Call Identifier 


IVI 


Alphanumeric handle 


Call-ID header 


Complete call leg 
(Call-ID, To, 
From) should 
better identified 
the call 


Codec 



(notes 1 and 2) 


List of possible codecs 


SDP parameter 
encoding name in 
a=rtpmap: lines 


note 3 


Transcode count 



(note 4) 


Number of codec 
transcoding 


Number of SDP lines 
starting with 
a=rtpmap: and with 
different encoding 
name set 


note 3 


Next Domain Egress 
point 





Network specific address 


SDP parameter c= 
and port set in SDP 
parameter m=audio 


A SDP parameter 
a= has to be set 
to sendrcv value. 


Result 


M 


- Call established 

- Rejection cause 

Called user busy 
No compatible 
codec available 


-200 OK 

-486 Busy here 
-415 Unsupported 
Media Type 




NOTE 1 : The list of codecs shall be limited to a single entry in the response. 

NOTE 2: This element shall be included if the result of the request is 'Call established'. 

NOTE 3: This element shall be included if the result of the request is 'Call established'. 

NOTE 4: For a RTP/AVP transport (parameter SDP m=) according to RFC 1890 [14] and RFC 2327 [11]. 



Table 30: Mapping of SIP to TCC_CallRelease request exchanged between CFEII/CalledUser 



TCC CallRelease request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Call Identifier 


M 


Alphanumeric 
handle 


Call-ID header 


Complete call leg (Call-ID, To, 
From) should better identified the 
call 


CauseCode 


IVI 


- Userlnitiated 

- network Initiated 


None 


In BYE request always set to 

Userlnitiated 

In CANCEL request it depends of 

the context 



Table 31 : Mapping of SIP to TCC_CallRelease response exchanged between CalledUser/CFEII 



TCC CallRelease response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Call Identifier 


M 


Alphanumeric handle 


Call-ID header 


Complete call leg (Call-ID, To, From) 
should better identified the call 


Result 


M 


- Successful 

- Failed 


-200 OK 
-4XX to 6XX 
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7.5 Simple call functional entity actions mapping 

Actions at CFE5, CFE8 and CFEIO concerning media reservation are out of scope. Proxies in charge of calling and 
called User have been considered to be stateful. 

Table 32: Mapping of SIP to Simple call action at CFE1, CFE2 



TIPHON Action 
number 


SIP behaviour 


101, 201,203 


Check the proxy authorization header 


102 


Transmits to the client part the received INVITE 


103 


Forwards provisional response 


104 


Forwards 2XX response 


105 


Forwards the BYE/CANCEL 


106 


None 


107 


Forwards the 404 response 


108 


Sends a 401 response 


109 


Forwards the 603 response 


110 


Forwards the 488 response 


111 


Forwards the 415 response 


112 


Forwards the 486 response 


113, 114 


Transmits to the server part the CANCEL, answers to the UA to its CANCEL request with 
200 Ok and to its INVITE with a 487 (Request terminated) 



Table 33: Mapping of SIP to Simple call action at CFE3, CFE4 



TIPHON Action 
number 


SIP behaviour 


301,401 


Build request URI, update route set according to the received INVITE and eventually DNS 
information. 


302 


Out of scope (RSVP), proxy will have to record itself in a record-route header. 


303 


Forwards the INVITE. 


304 


Transmits to the server part the provisional response. 


305 


Out of scope (RSVP) the media connect in SIP will be done one receipt of the ACK. 


306 


Transmits to the server part 2XX response. 


307 


The received BYE is transmitted to a client part. The release of the resource is out of 
scope(RSVP). 


308 


Forwards the BYE response. 


309 


Transmits a 404 answer to server part. 


310,311 


Transmits the 603 response to server part. The release of the resource is out of 
scope(RSVP). 


312 


Transmits the 415 response to server part. The release of the resource is out of 
scope(RSVP). 


313 


Transmits the 486 response to server part. The release of the resource is out of 
scope(RSVP). 


314 


Forwards the CANCEL request. The release of the resource is out of scope (RSVP). 
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Table 34: Mapping of SIP to Simple call action at CFE6, CFE7 



TIPHON Action 
number 


SIP behaviour 


601,701 


Build request URI, update route set according to the received INVITE and eventually DNS 
information. 


602 


Out of scope (RSVP), proxy will have record itself in a record-route. 


603 


Sends the updated INVITE to the proxy of the destination user. 


604 


Forwards provisional response. 


605 


Out of scope (RSVP), proxy will have record itself in a record-route. The media connect in 
SIP will be done one receipt of the ACK. 


606 


Forwards 2XX response. 


607 


Forwards the BYE. The release of the resource is out of scope(RSVP). 


608 


Forwards the BYE/CANCEL response. 


609 


Sends/Forwards a 603 response to CFE3. 


610 


Sends/Forwards a 488 response to CFE3. 


611 


Sends/Forwards a 41 5 response to CFE3. 


612 


Sends/Forwards a 404 response to CFE3. 


613 


Forwards the CANCEL The release of the resource is out of scope (RSVP). 


614 


Forwards the CANCEL response. 


615 


Update SDP body, sends an ACK to CFE9 an sends a re-INVITE. 


616 


Sends a 2XX answer. 



Table 35: Mapping of SIP to Simple call action at CFE9 



TIPHON Action 
number 


SIP behaviour 


901 


Out of scope (RSVP). 


902 


Transmits to the client part the received INVITE. An Alerting could not be sent until a 
provisional response will be received from the User Agent. 


903 


Out of scope (RSVP). 


904 


Forwards 2XX response. 


905 


Forwards the BYE. The release of the resource is out of scope(RSVP). 


906 


None. 


907 


Sends/Forwards a 603 response to CFE6. 


908 


Sends/Forwards a 415 response to CFE6. 


909 


Sends/Forwards a 486 response to CFE6. 


910 


Transmits to the client part the received CANCEL that will wait the answer before an answer 
will be sent to CFE6. The release of the resource is out of scope (RSVP). 


911 


None. 



Table 36: Mapping of SIP to Simple call action at CFE11 





TIPHON Action 
number 


SIP behaviour 


1101 


Forwards the INVITE to the UA 


1102 


Transmits to the server part the INVITE 2XX response 


1103 


The received BYE is transmitted to a client part. 


1104 


The proxy will have to wait the final answer o the BYE before sending any confirmation. 


1105 


None 


1106 


Transmits a 415/486 answer to server part. 


1107 


Forwards the CANCEL request 


1108 


Transmits to the server part the CANCEL 2XX response and wait for a final response from 
the UA concerning the INVITE to be acknowledged. 



7.6 



Timers 



The timer defined in meta-protocol for simple call concerns resource reservation which is out of scope in the present 
document. 
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7.7 Conclusion 



Resource reservation is not in SIP scope, other protocols like RSVP will have to be studied. 

The matching of information element for QoS and traffic descriptors to SIP is unsuccessful. However, those parameters 
can be partially expressed depending of the RTP/AVP profile chosen in SDP. 

Alerting is not supported as it is described in the Meta-Protocol, the closer behaviour in SIP is answering with 
provisional responses but they are sent by the UA and not by the Proxy that forwards them only. 

In case of a successful call set-up, call release cannot be confirmed before the remote UA answer. Additional release 
flows action between CFE9 and CFEl 1 (action 911) or CFEl and CFE3 (action 106) cannot be mapped. When the call 
clear occurs before the call-setup is complete, the UA will receive a final 487 answer to its INVITE request that has no 
equivalence in the meta protocol flow. The stateful proxy will not wait for the answer from the other UA to send both 
final responses to the CANCEL and to the INVITE. 

The media path is established on receipt of an ACK that has no equivalence in the meta-protocol flow. Moreover, all 
final responses (even unsuccessful) to an INVITE have to be confirmed with an ACK. 

A request in SIP can be forked. Several forwarding destinations can be chosen, and be answered with several response. 
This is not reflected in the meta-protocol. A one to one mapping at flow level cannot be done. 



8 Media Control service 

8.1 Introduction 

The goal of this clause is to try to map as far as possible the media control service defined in the Meta-protocol 
document TS 101 882-4 (see bibHography) with SDP (RFC 2327 [11]). RSVP or other equivalent protocol have been 
considered out of the scope of this clause. 

As defined in TS 101 882-4 (see bibliography), the Media Control (MC) service establishes the media elements 
required to support both call and bearer. It is used to establish a QoS controlled transport capability in accordance with 
the QoS class identified by the call control meta-protocol. 

MC does the following: 

• maintains the media state; 

• establishes and releases media elements. 

SDP allows to describe and negotiate parameters concerning the media. SDP session descriptions are included the body 
part of SIP messages while the session is established. SDP protocol does not include signalling protocol and only a 
static mapping for data descriptions has been done. 

8.2 Media Control functional entities mapping 

Table 37: Mapping of SIP entities to TIPHON Media Control functional entities 



TIPHON functional element 


SIP entities 


Identity 


TIPHON Description 


Call Control 
Agent 


Request reservation, allocation or release of 
specific media stream capabilities 


Part of UA, Proxy 


MFE1 


Media control coordination 


Part of UA, Proxy 



8.3 Media Control information flow Mapping 

The mapping is done with the SDP description contained in the body part of SIP a message. Because there is no 
message information described while the reservation is done, only the request could be statistically described and 
derived from the SIP message. 
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8.3.1 Relationship ra (CCA/MFE1 ) 

Because there is no exchange described while the reservation is done, only the MediaReservation request could be 
statistically described and is concerned by SDP parameters set in the SIP message. 

Table 38: Mapping of SIP to MediaReservation request from CCA to MFE1 



MediaReservation request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Session Handle 


M 


Alphanumeric 
'handle' 


SDP session id set 
in 0= 




IVledia 


M 


enumerated 


SDP parameter 
m=audio 




Media resource 


M 










mediaResourceHandle 





Integer 


SDP pay load type 
set in m= and 
reused in a= 




rxFlowDescriptor 









Attribute set 

when 

a=recvonly 




FlowDescriptorHandle 





Integer 


payload type set in 
a= 




codecDescriptor 


M 




derived from 
RTP/AVP profile set 
in a=rtmap:xxx 






codecID 


M 


VisibleString 


None 




framesPerPacket 


M 


Integer 


None 




SilenceSupressionEnabled 


M 


BOOLEAN 


None 




codecSpecificParameters 


M 


VisibleString 


None 




transportDescriptors 


M 










TransportQosParams 


M 




could be derived 
from SDP parameter 
a= quality:<quality> 






maximumDelay 


M 




None 






maxDelayVariation 


M 




None 






maxlVlean PacketLoss 


M 




None 




TraficDescr 


M 




derived from SDP 
parameter a=ptime 






peakFrameRate 


M 


Integer 


None 






framesPerPacket 


M 




None 




ingressAddress 


M 


E164/E212/IP 
address 


Address set in SDP 

Parameter 

c= plus port set in 

m=audio of the initial 

offer 




destTransportDomain 


M 


E164/E212/IP 
address 


Address set in SDP 

Parameter 

c= plus port set in 

m=audio of the final 

answer 




txFlowDescriptor 









Attribute set 

when 

a=sendonly 




FlowDescriptorHandle 





Integer 


payload type set in 
a= 




codecDescriptor 


M 




derived from 
RTP/AVP profile set 
in a=rtmap:xxx 






coded D 


M 


VisibleString 


None 




framesPerPacket 


M 


Integer 


None 




SilenceSupressionEnabled 


M 


BOOLEAN 


None 




codecSpecificParameters 


M 


VisibleString 


None 




transportDescriptors 


M 










TransportQosParams 


M 








maximumDelay 


M 




None 
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MediaReservation request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 










maxDelayVariation 


M 




None 




maxMeanPacketLoss 


M 




None 




TraficDescr 


M 




derived from SDP 
parameter a=ptime 






peakFrameRate 


M 


Integer 


None 




framesPerPacket 


M 




None 




ingress Address 


M 


E164/E212/IP 
address 


Address set in SDP 
parameter c= plus 
port set in m=audio 
of the initial offer 




destTransportDomain 


M 


E164/E212/IP 
address 


Address set in SDP 
parameter c= plus 
port set in m=audio 
of the final answer 




connectionPriority 


M 


Normal, Emergency 


None 





8.4 



Conclusion 



Very few elements from the media Control meta-protocol can be mapped. Other protocols like RS VP will need further 
study. 



9.1 



Transport 



Introduction 



The Transport meta-protocol TS 101 882-5 [7] is not stable yet and this clause will need further study. 

1 Supplementary services 

The meta-protocol for supplementary services has not been defined yet and the mapping with SIP could not be done. 
No supplementary service on its own is defined in SIP, other SIP extension IETF RFC will have to be considered. 

1 1 Control of end-to-end Quality of Service 
11.1 Introduction 

As stated in TS 102 024-3 [3], end-to-end QoS Signalling is used within a TIPHON network to ensure that a caller is 
provided with an end-to-end connection having at least the QoS class subscribed to or a lower QoS class if this is 
acceptable to the user. A QoS level may either be requested explicitly by the user on a call-by-call basis or may be 
predefined as part of the user's subscription. Additionally, the caller may be able to take specific actions if the QoS 
moves outside the accepted level during an established call. 

For each element in each of the QoS Signalling information flows, the tables identify where and how the information 
can be obtained or sent in the Session Initiation Protocol (SIP) (RFC 3261 [9]) and its associated protocols, the Session 
Description Protocol (SDP) (RFC 2327 [11]), and the Real-Time Protocol Audio- Video Profile (RTP/AVP) 
(RFC 1890 [14]). The underlying architectural model of SIP is simpler than the TIPHON model as there is no provision 
for guaranteed QoS. 
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1 1 .2 Control of end-to-end Quality of Service functional entities 
mapping 

Table 39: Mapping of SIP entities to TIPHON control of end-to-end Quality of Service entities 



TIPHON functional element 


SIP entities | 


Identity 


TIPHON Description 


User at Home 


Roaming User 


Calling User 


The application at the calling user"s terminal 
which instigates the service request. 


UA Client 


UA Client 


QFE1 


The service agent that processes the calling 
user"s request for end-to-end QoS signalling 


Application in the 
home stateful Proxy 
in the same current 
domain of the UA 
(Server Part) 


Application in the 
home stateful Proxy 
(Server Part) 


QFE2 


The originating QoS coordination function. 
This QFE is responsible for negotiating and 
establishing a particular QoS on behalf of the 
calling user. 


Application in the 
home stateful Proxy 
in the same current 
domain of the UA 
(Client Part) 


Application in the 
home stateful Proxy 
(Client Part) 


QFE3 


The terminating QoS coordination function. 
This QFE is responsible for establishing a 
particular QoS on behalf of the called user. 


Application in the 
stateful Proxy of 
called Domain 


Application in the 
stateful Proxy of 
called Domain 


QFE4 


The service agent that processes an 
incoming call to the called user 


stateful Proxy of 
called Domain 


stateful Proxy of 
called Domain 


QFE5 


The QoS policy control function associated 
with the calling user"s service provider 


Application in the 
home stateful Proxy 
in the same current 
domain of the UA 
(Registrar part) 


Application in the 
home stateful Proxy 
(Registrar part) 


QFE6 


The originating call routing function, providing 
routing information and number/address 
translations; 


DNS 

server/Location 

Server 


SIP routing rules, 
DNS server. 
Location Server 


QFE7 


The transport coordination function serving 
the called user 


stateful Proxy of 
called Domain 


stateful Proxy of 
called Domain 


QFE8 


An intervening QoS coordination function. 
This QFE is responsible for establishing a 
particular QoS within an intervening domain. 


Application in an 
intermediate stateful 
Proxy 


Application in an 
intermediate stateful 
Proxy 


QFE9 


An intervening transport coordination 
function. 


Intermediate stateful 
Proxy 


Intermediate stateful 
Proxy 


Called User 


The application in the called user"s terminal 
at which the service request is terminated 


UA Server 


UA Server 



1 1 .3 Control of end-to-end Quality of Service flows mapping 

SIP and its associated standards are intended for providing communications without a guarantee of QoS. As a 
consequence, the underlying model is different from the TIPHON model. SIP assumes a direct, but uncontrolled media 
path to the destination whereas TIPHON assumes linked transport domains carefully controlled by service domains to 
ensure that sufficient resources are available that the desired QoS can be achieved. There is, therefore, no functional 
equivalence in SIP or SDP to the messages that pass between a TIPHON service domain and the corresponding 
transport domain (TRMReserve, TRMConnect and TRMRelease) and, thus, no mapping of meta-protocol information 
elements to SIP, SDP or RTP/AVP signals is possible. 
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Table 40: Mapping of SIP messages to TIPHON Control of end-to-end Quality of service lUIPMUs 



TIPHON message 


Relationship ID 


SIP messages 


OrigQoSEstab 


request 


Calling User->QFE1 


SDP included in INVITE request 


response 


QFE1<- Calling User 


SDP included in Final responses 


QoSEstab 


request 


QFE1->QFE2 
QFE3->QFE4 


None 


response 


QFE2<-QFE1 
QFE4<-QFE3 


None 


QoSEstab 


request 


QFE2->QFE8 
QFE8->QFE3 


SDP included in INVITE request 


response 


QFE8<-QFE2 
QFE3<-QFE8 


SDP included in Final responses 


DestQoSEstab 


request 


QFE4-> Called User 


SDP included in INVITE request 


response 


Called User<-QFE4 


SDP included in Final responses 


QoSPolicy 


QFE1<->QFE5 


None/the Common Open Policy Service (COPS) 
protocol [1 7] 


TRMReserve 


QFE1<->QFE6 
QFE8<->QFE9 
QFE3<->QFE7 


None 


TRMConnect 


CD CT> 1^ 
LU LU LU 
LL LL LL 
OOO 
AAA 

V V V 
1- CO CO 
LU LU LU 
LL LL LL 
OOO 


None 


TRMRelease 


QFE1<->QFE6 
QFE8<->QFE9 
QFE3<->QFE7 


None 
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1 1 .4 Control of end-to-end Quality of Service information flow 
data mapping 

1 1 .4.1 Relationship ra (CallingUser/QFE1 ) 



Table 41 


: Mapping of SIP to OrigQoSEstab request from CallingUser 


to QFE1 


OrigQoSEstab request/indication 


TIPHON 


SIP/SDP/RTP/AVP 


Information element 


Status 


Value 


Mapping 


Notes 


QoSServiceClass 


M 


enumerated Value 


The suggested attribute for quality 
(a=quality:<quality>) in SDP offers 
an integer range of to 10. These 
can be mapped thus: 

TIPHON Class 1 

1 TIPHON Class 2A 

2 TIPHON Class 2M 

3 TIPHON Class 2H 

4 TIPHON Class 3 

5 Predefined 

6-10 Non-standardized 
OoS classes 


The 'quality' attribute is 
intended primarily for 
video media streams but 
there is nothing in 
RFC 2327 [11] which 
would prevent it being 
used for voice QoS 

Although the range 
suggested for the SDP 
quality attribute is to 
10, there is no reason 
why this could not be 
extended to the TIPHON 
range of to 255 


Called user ID 


M 


TIPHON user name 


SIP-URI contains in To header 




Codec 


M 


- List of possible 


SDP parameter encoding name in 


As a default, the Frames 






codecs 


a=rtpmap: lines or 


per packet should be set 






- Codec type 


SDP media announcements (m) 


to the value 20 in this 






- Frames per 


sub-field, media formats. This can 


case (see note) 






packet 


carry a list of RTP/AVP codes for 
available codec types. For 
example, to use G.71 1 , it is 
necessary to select the |a-Law PCM 
code '0', as follows: 
m=audio 49232 RTP/A VP 

No equivalent to Frames per 
packet 




NOTE: The value of 20 G.71 1 sarr 


iples per packet is not e 


sntirely arbitrary but is based on the common use of 20 or 30 in 


existing devices which pac 


ketize G.71 1 sample st 


reams. However, there appears to be 


no published research 


on determining the optimut 


71 value. 
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Table 42: Mapping of SIP to OrigQoSEstab response from QFE1 to CallingUser 



OrigQoSEstab response/confirmation 


TIPHON 


SIP/SDP/RTP/AVP 


Information element 


Status 


Value 


Mapping 


Notes 


Codec 




(notes 1 
and 2) 


List of possible codecs 


SDP parameter encoding 
name in a=rtpmap: lines 


only one a=rtmap 
SDP line shall be 
present with a port 
set to a non null value 
in the 
m= SDP line. 


Result 


M 


- End-to-end QoS Established 

- with requested QoS 

- Rejection cause 

- Requested QoS not 
available 

- Called user unknown 

- No compatible codec 
available 

- Policy Rejection 


SIP INVITE response 200 

SIP INVITE request failure 

- 406: Not acceptable 

- 404: Not found 

- 415: 
Unsupported media type 

- 401 not authorized 




NOTE 1 : The list of codecs shall be limited to a single entry in the response. 

NQTE 2: This element shall be included if the Result element is set to 'end-to-end QoS Established'. 



1 1 .4.2 Relationship re, rd (QFE2/QFE8/QFE3) 

Table 43: Mapping of SIP to QoSEstab request exchanged between QFE2/QFE8/QFE3 



QoSEstab request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Calling user ID 


M 


TIPHQN user name 


SIP-URI contains 
in From header 


For simple mapping to 
TIPHQN user name, the 
From field should be 
formulated as a 
telephone-url as 
specified in 
RFC 2806 [16] 


Called user ID 


M 


TIPHQN user name 


SIP-URI contains 
In To header 


For simple mapping to 
TIPHQN user name, the 
To field should be 
formulated as a 
telephone-url as 
specified in 
RFC 2806 [16] 


Transport QoSparameter 


M 


TransportParams 


SDP parameters 


a=quality:<quality> SDP 
line could be used 




maximumDelay 


M 


Microseconds 


None 




maxDelayVariation 


M 


Microseconds 


None 




maxMeanPacketLoss 


M 


PercentXIOOO 


None 




Transportparametersqualifier 


M 


Enumerated: 

totalRemainingBudget, 

budgetAvailableForDomain 


None 


This information could be 
carried in aTlPHQN- 
defined attribute (a) 
sub-field in SDP 
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QoSEstab request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


TrafficDescriptor 


M 


TrafficDesc 


SDP parameters 


Derived to a=ptime: 




peakFrameRate 


M 


Integer 


None 




maxFrameLength 


M 


Integer 


None 




Codec 


M 


List of possible codecs 

- Codec type 

- Frames per packet 


SDP parameter 
encoding name in 
a=rtpmap: lines 


SDP media 
announcements (m) 
sub-field, media formats. 
This can carry a list of 
RTP/AVP codes for 
available codec types. 
For example, to use 
G.711, it is necessary to 
select the |a-Law PCM 
code '0', as follows: 
m=audio 49232 
RTP/AVP 

The Frames per packet 
Information could be 
carried as a TIPHON- 
defined attribute (a) 
sub-field in SDP 

(see note) 


Destination Service domain 





Domain address 


Connection 
address sub-field in 
the SDP 

connection data © 
field 


Current edition of SDP 
supports only IPV4 
addresses 


NOTE: For a RTP/AVP transport (parameter SDP m=) according to RFC 1890 [14] and RFC 2327 [11]. 



Table 44: Mapping of SIP to QoSEstab response exchanged between QFE2/QFE8/QFE3 



QoSEstab response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Codec 





List of possible codecs 


SDP parameter 


only one a=rtmap 




(notes 1 


- Codec type 


encoding name in 


SDP line shall be 




and 2) 


- Frames per packet 


a=rtpmap: lines 


present with a port 
set to a non null 
value in the 
m= SDP line. 


Result 


M 


- Requested OoS available 

- Rejection cause 

- Requested QoS not 
available 

- Called user unknown 

- No compatible codec 
available 


- 200 OK 

- 603 Decline 

- 404 not found 

- 415: 
Unsupported media type 




NOTE 1 : The list of codecs shall be limited to a single entry in the response. 




NOTE 2: This element shall be included if the result of the request is 'Call established'. 
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1 1 .4.3 Relationship rf (QFE4/CalledUser) 

Table 45: Mapping of SIP to DestQoSEstab request exchanged between QFE4/CalledUser 



DestQoSEstab request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Calling user ID 


M 


TIPHON user name 


SIP-URI contains 
in From header 


For simple mapping to TIPHON 
user name, the From field 
should be formulated as a 
telephone-url as specified in 
RFC 2806 [16] 


Transport QoSparameter 


M 


TransportParams 


SDP parameters 


a=quality:<quality> SDP line 
could be used 




maximumDelay 


M 


Microseconds 


None 




maxDelayVariation 


M 


Microseconds 


None 




maxlVlean PacketLoss 


M 


PercentXIOOO 


None 




Codec 


M 


List of possible codecs 

- Codec type 

- Frames per packet 


SDP parameter 
encoding name in 
a=rtpmap: lines 


SDP media announcements 
(m) sub-field, media formats. 
This can carry a list of 
RTP/AVP codes for available 
codec types. For example, to 
use G.71 1 , it is necessary to 
select the n-Law PCM code '0', 
as follows: 

m=audio 49232 RTP/A VP 
The Frames per packet 
information could be carried as 
a TIPHON-defined attribute (a) 
sub-field in SDP 
(see note) 


NOTE: For a RTP/AVP transport (parameter SDP m=) according to RFC 1 890 [1 4] and RFC 2327 [11]. 



Table 46: Mapping of SIP to DestQoSEstab response exchanged between QFE4/CalledUser 



DestQoSEstab response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Codec 




(notes 1 
and 2) 


List of possible codecs 

- Codec type 

- Frames per packet 


SDP parameter encoding 
name in a=rtpmap: lines 


only one a=rtmap SDP 
line shall be present with 
a port set to a non null 
value in the m= SDP line. 


Result 


M 


Indicated codec 
selected 
Rejection cause: 
Codecs not supported 


- 200 OK 

- 415: 
Unsupported media type 




NOTE 1 : The list of codecs shall be limited to a single entry in the response. 

NOTE 2: This element shall be included if the result of the request is 'Indicated codec selected'. 



1 1 .4.4 Relationslnip rg (QFE1 /QFE5) 



The SIP model does not include a policy entity and so there is no equivalent to the QoSPolicy protocol messages. 
Consequently, it is not possible to make any mapping between the TIPHON meta-protocol and SIP in this area. 
However, the Common Open Policy Service (COPS) protocol (RFC 2748 [17]) used by RSVP exists specifically for 
this purpose. Its underlying architectural model is similar to the TIPHON QoS model in that COPS provides 
communication between a network node and a policy entity referred to as the Policy Decision Point (PDP). 
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Table 47: Mapping of SIP to QoSPolicy request exchanged between QFE1/QFE5 



QoSPolicy request/indication 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Calling user ID 


M 


TIPHON user name 


COPS REQ 
C-num=3 In Interface 
C-type=1 (IPv4) or 2 {IPv6) 


COPS permits only an IPv4 or 
IPv6 address. The TIPHON 
user name would need to be 
converted from an E.I 64 
number before use 


Called user ID 


M 


TIPHON user name 


COPS REQ 

C-num= 4 Out Interface 

C-type=1 (IPv4) or 2 {IPv6) 


COPS permits only an IPv4 or 
IPv6 address. The TIPHON 
user name would need to be 
converted from an E.I 64 
number before use 


Transport 
QoSparameter 


M 


TransportParams 


No equivalent 


This information could be 
carried in the C//enfS/ object 
(C-num = 9, C-type = 1) 




maximumDelay 


M 


Microseconds 


None 




maxDelayVariati 
on 


M 


Microseconds 


None 




maxMeanPacke 
tLoss 


M 


PercentXIOOO 


None 




QoSServiceClass 


M 


enumerated Value 


No equivalent 


This information could be 
carried in the C//enfS/ object 
(C-num = 9, C-type = 2) 



Table 48: Mapping of SIP to QoSPolicy response exchanged between QFE1/QFE5 



QoSPolicy response/confirmation 


TIPHON 


SIP 


Information element 


Status 


Value 


Mapping 


Notes 


Result 


M 


- Call permitted 

- Rejection cause 


COPS DEC 

C-num = 6, C-type = 1 ; 4 

COPS DRQ 


C-Type 1 ; 

4 = Admit Request 






- Service not subscribed 


C-num = 5 


C-Type 1 , 






to 


C-type = 1 ; 9 


9 = Unsupported 






- Service currently not 




decision 






available 


C-type = 1 ; 7 


C-type 1 , 

7 = Insufficient 

resources 



1 1 .5 Control of end-to-end Quality of Service functional entity 
actions mapping 

Those actions are application dependant without equivalence in SIP behaviour. 

11.6 Timers 

The timer defined in the meta-protocol for simple call concerns resource reservation which is out of scope in the present 
document. 
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11.7 Conclusion 



Although, with some assumptions, it is possible to show how SIP and SDP can be mapped to the TIPHON QoS meta- 
protocol between users and service domains and between service domains, there is no provision in the current version of 
the IETF series of standards for any signalling between service domains and transport domains. Since this signalling is 
fundamental to the provision of guaranteed QoS in the TIPHON model, there is a significant gap in the mappings. To 
achieve full mapping, there needs to be considerable modifications to the SIP-related protocols. This should include: 

1) the clear recognition that there are entities which can at least act as service domains between the calling user 
and the called user; 

2) the addition within the SIP/SDP architecture of transport domains; 

3) the addition of a new protocol specification for signalling between service domains and transport domains; 

4) the extension of COPS to include fields for carrying QoS Class or Transport QoS Parameters; 

5) the extension of SDP to include fields for carrying QoS class. Transport QoS Parameters, the Transport 
Parameters Qualifier, the Traffic descriptor and Codec lists. 



12 Security service 

This clause is for further study. 
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